寫在前面：
這個系列主要想記錄我們在研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表個人現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。
今天談的 Mock Audit（模擬稽核），也不是 CRA 規定企業一定要執行的活動，而是當制度、流程與 Evidence 逐漸建立之後，我們可以嘗試採用的一種驗證方式：在 CRA 全面適用以前，實際挑一個 Product，從頭到尾跑一次，看看整套機制是不是真的串得起來。
Day 26 談到 Evidence Management（證據管理）時，最後留下了一個想法：
Repository 解決的是「東西放在哪裡」，Traceability 解決的是「這份東西到底證明了什麼」。
但再往下，其實還有第三個問題：
這些東西真的串得起來嗎？
做到現在，Product Classification（產品分類）有了、Cybersecurity Risk Assessment（資安風險評估）有了、SSDLC（安全軟體開發生命週期）建了、SBOM 可以產了、PSIRT 建立了、Supplier Security（供應商資安）也開始做了，Technical Documentation（技術文件）也逐漸整理起來。
如果 Dashboard 上面全部都是綠燈，是不是就代表：
CRA Ready？
可能還不能這麼快下結論。
因為每一個 Process 都存在，跟這些 Process 能不能在同一個 Product 上真正串起來，其實是兩件不同的事情。
所以到了這個階段，我們可以嘗試做一次 End-to-End CRA Mock Audit。
一般 Compliance Review（合規檢視）很容易從 Requirement Checklist 開始。
例如：
Article 13？有。
Annex I？有。
SBOM？有。
PSIRT？有。
Technical Documentation？有。
最後得到：
95% Completed。
這種方式當然有價值，尤其在 Gap Assessment（差距分析）階段，很適合確認哪些 Requirement 還沒有被處理。
但如果 CRA 已經逐漸進入 Implementation（落實）階段，我們可以再增加另外一種測試方式。
不是：
Requirement-by-Requirement（逐項要求）。
而是：
Product-by-Product（逐項產品）。
也就是挑一個真正預計進入 EU Market 的 Product，從最前面的 Applicability（適用性）開始，一路往後 Trace。
假設今天抽到：
Product X，Version 3.2。
第一個問題可以先不要問：
「Risk Assessment 在哪裡？」
而是：
「為什麼 Product X 適用 CRA？」
接著再一路往下問：Product with Digital Elements（具數位元素產品）的判斷依據是什麼？Manufacturer（製造商）是哪一個 Legal Entity（法律實體）？Product 是否進入 EU Market？是否有需要考慮的 Exclusion（排除情形）？最後 Classification 是什麼？
這時第一條 Evidence Chain 就開始形成：
Product → Applicability → Classification → Decision Evidence
這一步很重要，因為如果連「為什麼這個 Product 被納入 CRA」都說不清楚，後面即使準備了很多 Technical Documentation，最前面的適用性判斷仍然可能缺少足夠的依據。
假設 Product X 最後被判斷為：
Default Category（預設類別）。
接著可以繼續往下追：
為什麼是 Default Category？
Classification Record（分類紀錄）在哪裡？
誰做 Assessment（評估）？
誰 Review（覆核）？
Product 後來有沒有增加新的 Function？
如果 Product 發生 Change，Classification 有沒有重新確認？
Mock Audit 在這裡要確認的，不只是：
「答案是什麼？」
還包括：
「這個答案是怎麼來的？」
因為幾年後真正重要的，可能不是還有人記得 Product X 是 Default Category，而是公司仍然找得到：
當初為什麼這樣判斷。
接下來就可以開始往 Product Security 深入。
例如 Product X 的 Intended Purpose（預期用途）是什麼？Reasonably Foreseeable Use（合理可預見使用）怎麼考慮？有哪些 Asset（資產）？有哪些 Attack Surface（攻擊面）？Threat Scenario（威脅情境）怎麼識別？Risk 又是怎麼評估的？
這時不要只確認：
「有 Risk Assessment。」
我們可以直接從裡面抽一個 Risk。
例如：
RA-017：Unauthorized Access（未授權存取）。
然後開始一路往下追。
假設 RA-017 對應一項 Security Requirement：
SR-023。
接著就可以繼續問：
SR-023 是什麼？
R&D 怎麼 Implement（實作）？
對應哪一個 Security Control（安全控制）？
怎麼 Verification（驗證）？
Test Case 是哪一個？
Test Result 在哪裡？
最後可能形成：
RA-017
↓
SR-023
↓
Security Control
↓
TC-041
↓
PASS
↓
Product X Version 3.2
這就是 Day 26 談到的 Evidence Chain。
如果這條 Chain 可以一路走完，它所能證明的事情，可能比單純看到一張「Annex I = 100% Completed」的 Checklist 更多。
因為它代表：
Requirement、Risk、Design、Implementation、Test 與 Evidence 之間真的有關係。
接下來可以直接要求：
「請提供 Product X Version 3.2 的 SBOM。」
注意，這裡不是只問：
「有沒有 SBOM？」
而是指定：
Product + Version。
拿到之後，可以確認 Component Version 是否清楚、Third-party Component 是否能識別、Open Source Component 是否有納入，以及這份 SBOM 是否真的對應 Product X Version 3.2。
接著再隨機挑一個：
Component A。
然後問一個更實際的問題：
如果明天 Component A 出現一個 Critical Vulnerability（重大漏洞），公司怎麼知道 Product X 有沒有受到影響？
到了這一步，SBOM 才真正從「有一份文件」，開始變成可以實際使用的 Product Security Capability。
因為 SBOM 本身不是終點。
真正的流程可能是：
Component
↓
Vulnerability Intelligence（漏洞情資）
↓
Product Impact Assessment（產品影響評估）
↓
PSIRT
↓
Remediation / Mitigation（修復／緩解措施）
↓
Customer Communication（客戶溝通）
所以 Mock Audit 到這裡，可以不再只看文件，而是直接加入 Scenario（情境）。
例如：
「今天 Component A 公布一個 Critical Vulnerability。」
然後開始問：
誰會收到資訊？
誰負責分析？
Product Owner 怎麼知道？
哪些 Product Version 受到影響？
R&D 怎麼評估 Fix / Mitigation？
PSIRT Case Record 留在哪裡？
這時測的已經不只是「SBOM 有沒有」，而是：
SBOM 能不能支援真正的 Vulnerability Response（漏洞應變）。
接著可以再增加一個條件：
這個 Vulnerability 已經有實際被利用的資訊。
這時就能進一步測試 CRA Article 14 的 Assessment Process（評估流程）。
例如誰啟動 Article 14 Applicability Assessment？誰負責判斷 Reporting Trigger（通報觸發條件）？24 小時 Early Warning（早期預警）與後續 Notification（通知）流程由誰負責？需要哪些資訊？Reporting Decision（通報決策）與相關 Evidence 又保存在哪裡？
由於 CRA Article 14 的部分通報義務自 2026 年 9 月 11 日起開始適用，如果現在要安排 CRA Readiness Test，這一段其實可以列為相對優先的驗證項目。
但這裡有一個界線需要注意：
Mock Audit 的目的不是替個案做法律判定，而是確認公司有沒有一套可以在時限內完成 Assessment、Decision、Escalation 與 Reporting 的機制。
這才是企業可以事先準備與驗證的能力。
這可能有點像故意找麻煩，但實際 Vulnerability 或 Incident 不會挑星期一上午 10 點發生。
所以可以繼續問：
Product Owner 休假怎麼辦？
PSIRT 有沒有 Backup Contact（備援聯絡人）？
Legal / Compliance 找得到嗎？
Reporting Account 誰有權限？
關鍵資訊拿不到時怎麼 Escalate（升級處理）？
這些事情平常只看 Procedure 不一定看得出問題。
Scenario 一跑，很快就可能知道：
Process 是 Operational（可實際運作），還是只在正常辦公時間看起來很完整。
假設剛剛的 Component A 是 Third-party Component（第三方元件）。
接著就可以繼續問：Supplier 是誰？Security Requirement 有沒有傳遞？Vulnerability Notification Mechanism（漏洞通知機制）有沒有建立？Security Fix 誰負責？Supplier Support 到什麼時候？EOL / EOS（生命週期終止／支援終止）怎麼通知？相關 Due Diligence（盡職調查）紀錄在哪裡？
這時 Supplier Security 就不再只是：
「Procurement 每年有做 Vendor Assessment。」
而是直接跟某一個 Product、某一個 Component 以及某一個 Product Risk 串在一起。
這樣的驗證方式，也更容易看出 Product Security Supply Chain（產品資安供應鏈）不同環節之間是否真的有連結。
下一題：
Product X 的 Support Period（支援期間）多久？
接著再問：怎麼決定的？跟 Product Lifecycle 對得起來嗎？相關資訊怎麼維護？Product Team 知不知道？
然後把剛剛的 Component A 再拿回來：
Supplier 對 Component A 的 Security Support Period，跟 Product X 的 Support Strategy 對得起來嗎？
例如 Product 預計維持較長的 Support，但其中一個 Critical Component 很早就停止 Security Support。
這時問題可能就不再只是 Supplier Management，而會開始涉及：
Product Lifecycle Risk（產品生命週期風險）。
這也是 Mock Audit 很值得驗證的一件事：不是只確認 Process 存在，而是找出不同 Process 接縫之間的 Gap。
假設 Product X 從 Version 3.1 升到 Version 3.2。
先問：
「改了什麼？」
假設答案是：
新增一個 Communication Interface（通訊介面）。
那就可以繼續往下追：Cybersecurity Risk Assessment 有沒有重新檢視？Threat Model 有沒有受到影響？Security Test 是否需要更新？SBOM 是否改變？Technical Documentation 是否同步？是否有執行相應的 Change Security Impact Assessment？
以及 Day 17 談過的：
是否需要進一步評估 Substantial Modification（實質修改）？
這一段其實特別值得測。
因為很多制度在：
第一次建立時都很完整。
真正容易斷掉的地方，反而是：
第二次、第三次 Product Change。
前面 Product、Risk、SBOM、Supplier、Change 都走過一輪後，再要求：
「請提供 Product X Version 3.2 的 Technical Documentation。」
接著確認 Product Description、Intended Purpose、Design / Architecture、Cybersecurity Risk Assessment、Annex I Mapping、適用的 Standards、Security Test Evidence、SBOM，以及其他支撐 Conformity 的相關資訊。
但這時重點已經不是：
Technical Documentation 有沒有一個 PDF。
而是：
裡面的資訊能不能跟剛才一路看到的 Product Reality 對得起來。
這兩件事情的差別其實非常大。
例如 Technical Documentation 寫的是：
Product Version 3.2。
結果 SBOM 是：
Version 3.1。
Risk Assessment 最後更新時 Product 還是：
Version 2.8。
Penetration Test Report 則：
看不出測試的是哪個 Build。
這時每一份文件可能都存在，Checklist 也可能全部打 Yes。
但整體：
不一定能形成可信的 Evidence Chain。
所以 Day 26 談的 Version Traceability（版本可追溯性），到了 Mock Audit 就會真正開始發揮作用。
既然 Product X 的 CRA Classification 已經確認，接著可以問：
Conformity Assessment Route（符合性評估路徑）是什麼？為什麼？
如果採取適用的 Internal Control / Self-assessment（內部控制／自我評估）方式，就要進一步確認 Supporting Evidence 是否完整。
如果產品情境需要 Third-party Conformity Assessment（第三方符合性評估），則可以再確認相關 Assessment Record、Certificate 或其他 Evidence 是否能與 Product Version 對應。
走到這裡：
Product Security 就開始正式接到 Product Compliance（產品合規）。
而這個 Interface，也可能是 CRA 導入過程中特別值得驗證的一個地方。
接著才是 EU Declaration of Conformity（EU DoC，歐盟符合性聲明）以及 CE Marking。
這裡要確認的重點仍然是：
它們跟前面的 Product 到底是不是同一個東西。
例如 Product Identification 是否一致？Applicable Legislation 是否正確？使用的 Standards / Specifications 是否與前面的 Conformity Basis 一致？Signatory 與內部核准程序是否清楚？
做到這裡，才真正從：
Product Security → Product Compliance → Market Release
一路串起來。
因為 CRA 並不是 Product Release 之後就停止。
所以還可以繼續問：Product X 現在有沒有 Open Vulnerability？Vulnerability Monitoring 誰負責？Security Update 怎麼 Release？Customer 怎麼取得？Support Period 還剩多久？Product Change 怎麼持續被 Review？
也就是把 Audit Scope 從：
Pre-market（上市前）
一路延伸到：
Post-market（上市後）。
這樣才比較接近完整的 Product Cybersecurity Lifecycle（產品資安生命週期）。
如果把剛才的內容縮成一條路徑，大概會是：
Product Inventory
↓
CRA Applicability
↓
Classification
↓
Cybersecurity Risk Assessment
↓
Security Requirements
↓
SSDLC / Implementation
↓
SBOM / Component Management
↓
Security Verification / Testing
↓
Supplier Security
↓
PSIRT / Vulnerability Handling
↓
Article 14 Assessment / Reporting Process
↓
Technical Documentation
↓
Conformity Assessment
↓
EU DoC / CE
↓
Post-market / Support
如果這整條真的可以跑完，而且 Evidence、Owner、Version 與 Decision 都能對得起來，至少可以比較有信心地說：
這個 Product 的 CRA Process 大致串起來了。
如果公司有幾百甚至幾千個 Product，當然不可能每一個都做完整的 End-to-End Mock Audit。
所以可以考慮採：
Risk-based Sampling（風險導向抽樣）。
例如優先考慮：
如果公司本身有 Important / Critical Products，也可以依實際風險與準備需求考慮納入。
相較於完全 Random Sampling，Risk-based Sampling 的好處是：
在還來得及改善的時候，盡量找到制度真正脆弱的地方。
假設第一次 End-to-End Mock Audit 跑完，找到 20 個 Gap。
例如 Product Owner 不清楚、SBOM Version 對不起來、Supplier Support Period 不知道、Article 14 Backup Contact 沒建立、Test Evidence 找不到，或者 Technical Documentation 沒有跟 Product Change 更新。
其實不用太意外。
因為：
這本來就是 Mock Audit 的目的。
如果這些問題能在正式全面適用前的 Internal Review、Exercise 或 Mock Audit 被發現，公司就還有時間改善。
所以：
Mock Audit 的價值不是證明我們已經準備得很好，而是提早發現我們哪裡還沒有準備好。
這兩者看起來很像，但管理上的意義完全不同。
如果 Mock Auditor 就是負責建立 CRA Process 的人，他可能知道每一份 Evidence 在哪裡、知道哪個人要找，甚至看到一個流程斷點時，會下意識地幫忙把它補起來。
所以反而可以考慮找一個：
了解 Security / Compliance，但不熟這個 Product 的人。
然後讓他按照正式 Process 去找 Owner、Evidence、Decision 與 Record。
如果一個不熟 Product 的人仍然可以沿著制度把整條 Chain 走完，至少代表：
Knowledge 已經進入 Process，而不是只存在某幾個人的腦袋裡。
這其實也是制度成熟度一個很實際的驗證方式。
假設 Mock Audit 過程中發現 Product X 有一個 High Residual Risk（高殘餘風險）。
R&D 認為 Fix 會 Delay Release，Product Team 認為一定要準時上市，Security 則認為目前的 Risk Treatment 不足。
這時可以問：
誰決定？
Decision Authority（決策權責）在哪裡？Risk Acceptance（風險接受）由誰核准？需要哪些資訊？Decision Record 留在哪裡？
如果答案是：
「到時候再找主管討論。」
那可能代表：
Governance 還有 Gap。
所以 End-to-End Mock Audit 最後測到的，其實已經不只是 Document、Tool 或 Process。
它還會測到：
Organization Decision-making（組織決策能力）。
而這也剛好回到 Day 20 談過的 CRA RACI 與 Governance。
到了這個階段，對 CRA Audit 的思考可以慢慢從：
Compliance Checklist
再往前一步變成：
End-to-End Product Traceability（端到端產品可追溯性）。
我們想確認的不只是：
「有沒有 Risk Assessment？」
而是：
Risk 有沒有變成 Security Requirement？Security Requirement 有沒有被 Implement？Implementation 有沒有被 Test？Test 有沒有留下 Evidence？Evidence 對不對得上 Product Version？
再往後，Product Change 發生時有沒有重新檢視？SBOM 能不能支援 Vulnerability Analysis？Supplier Support 跟 Product Lifecycle 對不對得起來？Technical Documentation 能不能反映實際 Product？上市之後 Vulnerability Handling 與 Support Mechanism 還有沒有人持續維護？
如果這整條 Chain 都可以走完，我們或許才能更有信心地說：
CRA 開始從「一套制度」，真正變成「一種 Product Security Capability」。
所以 Mock Audit 最大的價值，也不一定是最後開出幾個 Finding（發現事項）。
更重要的是：
在真正需要這套機制以前，先讓我們知道哪裡還跑不起來。
這也跟 Day 26 的 Evidence Management 接在一起：
Day 26 問的是：「Evidence 能不能追？」
Day 27 再往前一步問：「整個 Product Lifecycle 能不能一路追到底？」
以上仍然只是目前研究及參與 CRA 導入後的一些心得、解讀與想法，希望拿出來和大家交流。
CRA 並沒有規定企業一定要依本文方式執行 End-to-End Mock Audit。這比較像是把 Risk-based Audit（風險導向稽核）的思維，延伸到 Product Cybersecurity Compliance（產品資安合規）的一種嘗試。
當制度、流程、Owner 與 Evidence 都逐漸建立之後，與其只問「我們做完了多少？」，或許也可以找一個 Product，真的從頭到尾跑一次看看。
因為跑得完，才比較有機會知道：
這些原本分散在不同部門、不同流程、不同系統裡的 CRA 要求，是否真的已經串成一套可以運作的能力。
假設到了：
2027 年 12 月。
Product 完成評估，Procedure 建好了，SBOM 有了，PSIRT 跑得動，Technical Documentation 也整理完成，Conformity Assessment 的流程也已經建立。
這時：
CRA Project 可以結案了嗎？
可以結束的也許是：
Project。
但不能跟著結束的是：
Capability。
因為隔天可能出現新的 CVE，下個月 Product Release 新 Version，半年後 Supplier Component 宣布 EOL，一年後 Product Architecture 又發生 Change。
如果每一次發生這些事情，都還要重新把原本的 CRA PMO 找回來問：
「這個 CRA 要怎麼處理？」
那可能就需要重新思考：
我們完成的是 CRA Project，還是真正建立了 CRA Operating Model（營運模式）？
所以 Day 28，接著想聊的就是這個轉折：
如何讓 CRA 從一次性的 Compliance Project，慢慢變成 Product、R&D、Product Security、PSIRT、Supplier Management 與 Product Compliance 原本就會做的日常工作。
也就是：
CRA 專案結束之後，CRA 到底要「住」在哪裡？
iThome鐵人賽
看影片追技術